%Resolution: 854x480
%Duration: 596 seconds
%Fps: 24
%File Size: 220,5 MB
%Codec: AVI MP4
%'I' Frames: 103
%'Other' Frames: 14201

% Found by: ffmpeg -i video.mp4 -vf select="eq(pict_type\,I)" -vsync 0 -f image2 ~/Desktop/video%03d.jpg

\clearpage\section{Source Coding}
Here goes a section about conventional video coding. Maybe include short introduction to scalable versions as well (h.264 SVC). Following this, a subsection of effects of a packet loss in a video stream



\subsection{Effects of a Packet Loss}
Due to the structure of encoded video data, the effect of a packet loss in a video stream depends on not only the data contained in the lost packet, but on the data in the stream before and after the lost packet as well. 
If the data contained in a lost packet is information about P-frames, the error in the video stream depends on how much the video changes at the given point in the stream. However, if the lost packet contained info about an I-frame, every packet containing info about the same I-frame before and after the lost packet can be considered useless. Furthermore, when the I-frame is discarded, every following P-frame is useless. It is assumed that the decoder in question can handle losses in the data stream.


\section{Optimizing Source Coding}
% Why it is important
%	packet loss WILL happen eventually
% How it is done
% How it will benefit nc
%	Undecodable generations WILL occur due to packet loss
% How it will benefit uep/nc
%	Easier to protect information, when information is packed optimally.

A video streaming service on an unreliable data channel will eventually experience packet loss. Depending on the packet, and especially how the video is encoded, a packet loss can i the worst case scenario completely corrupt the video stream for a period of time. This section covers the trade-offs and tweaks needed in video coding to optimize a video stream with respect to an unreliable data link.

\subsection{Ideal Source Coding for Unreliable Streaming}
% Ideal source coding features for streaming services on an unreliable data link.
% 	Can be used chronologically when received (The data received can be used immidiately, no need to wait for more data)
% 		Transmission rate ''equals'' playback rate
% 	Data loss may not affect data received before and after lost data.
For a data stream on an unreliable data channel like WLAN broadcast it is desirable if a packet loss causes no damage to the stream, other than the information lost in the packet. This implies that data packets must not depend on other data in the stream.

Furthermore, ideally it should not be neccesary to transmit data with a higher rate than the playback rate at the receiving node. This minimizes the network load, increasing network friendliness. To do this, the transmitted data should also be used by the receiver in the sequential order the data was received. This also minimized the amount of buffering needed on the receiving node. \fxnote{Er der for meget netværk i ovenstående ifht sourcecoding? For generelt?}

% \subsection{Data Independency}
% Ideally, every byte of data should be independent of previous and future data, to prevent data loss from corrupting the stream unecessarily. 
%\clearpage\section{Video}

%\subsection{Analysis of Video Data}
%Preliminary investigation in video codecs regarding frame composition and datasize. In Table \ref{tab:testing} the stats for the reference video is shown.

%\begin{table}[h]
%\centering
%\footnotesize
%\begin{tabular}{l l l l l l l l l}
%Res. & Dur. [s] & Fps & Size [MB] & Container & Codec & Frames & I frames [\%] & Other frames [\%] \\ \hline
%854x480 & 596 & 24 & 186,8 & AVI & MP4 & 14304 & 0,72 & 99,28 \\
%%1280x720 & 596 & 24 & 332,2 & AVI MP4 & 14304 & 0,95 & 99,05 \\
%\end{tabular}
%\caption{Statistics for 'Big Buck Bunny' reference video encoded without audio.}
%\label{tab:testing}
%\end{table}

%Given the video in table \ref{tab:testing} a data analysis is performed. The reference video is transcoded for a number of different \textit{qscale} and \textit{GOP sizes} to determine any relations between these parameters. The \textit{qscale} parameter is an alternative way of choosing the quality (i.e bitrate) for a video. This allows for comparison between a video with the same \textit{qscale} but otherwise varying parameters\footnote{Transcoding with a hardcoded bitrate and varying e.g. GOP size will ensure the same total filesize but quality will be degraded for small GOP size. This comparison is not important at this moment.}.The \textit{GOP size} parameter effectively specifies the number of p-frames per I-frame. The analysis is summarized in Figure \ref{fig:gopstats}.

%\begin{figure}[h!]
%\centering
%\includegraphics[width=0.7\textwidth]{figs/gopstats}
%\caption{Comparison between gop size and total filesize for different video qualities.}
%\label{fig:gopstats}
%\end{figure}

%In Figure \ref{fig:bbb_q10_gop20_480p.png} the distribution and size of the I og P-frames is shown.

%\begin{figure}[h!]
%\centering
%\includegraphics[width=0.7\textwidth]{figs/bbb_q10_gop20_480p.png}
%\caption{Frame distribution for \textit{GOP size} 20 and \textit{qscale} 10.}
%\label{fig:bbb_q10_gop20_480p.png}
%\end{figure}

%In Figure \ref{fig:dist_gop20_size} the distribution of the data size of the GOP of the video.

%\begin{figure}[h!]
%\centering
%\includegraphics[width=0.7\textwidth]{figs/dist_GOP20_size.eps}
%\caption{Distribution of the data size of the individual GOP from the GOP20 test video.}
%\label{fig:dist_gop20_size}
%\end{figure}

%\subsection{Fitting video data to NC generations}
%SEE tex if needed!!!!?!?!?
%%In this subsection a way of fitting video data into NC generations is considered. As discussed earlier, a GOP size of 20 can be chosen before the total file size of a video grows significantly. A high relative frequency of I frames (i.e a small GOP) seems advantageous for streaming purposes and this parameter therefore remains fixed at 20. This leaves packet size and generation size as parameters that must be defined or at least bounded. An approach is considered where a GOP must be contained within one generation. The inequality \eqref{eq:fit_video_gen} describes this scenario.

%%\begin{align}
%%GOP_{x}&\leq G_{max}\cdot P_{load} &\text{[bytes]}\label{eq:fit_video_gen}
%%\intertext{Where:}
%%GOP_{x}&\text{ is the data size of a GOP with 1 I and (x-1) P frames.}&\text{[bytes]}\notag\\
%%G_{max}&\text{ is the maximum generation size.}&\text{[-]}\notag\\
%%P_{load}&\text{ is the payload size.}&\text{[bytes]}\notag\\
%%\end{align}

%%FIXME\fxnote{Include overhead of sublayers in equations...}

%%The Inequality \eqref{eq:fit_video_gen} states that the data size of a GOP must factor into the generation size and payload size with given constraints. When transmitting over WLAN it advantageous to keep the total packet size under the MTU\fxnote{Claim, can we back it up?.}. The packet budget follows in \eqref{eq:packet_budget}.

%%\begin{align}
%%MTU-&P_{load}-G\cdot \tilde{q}-O_{UDP}=0 &\text{[bytes]}\label{eq:packet_budget}
%%\intertext{Where:}
%%MTU&\text{ is the maximum transfer unit.}&\text{[bytes]}\notag\\
%%P_{load}&\text{ is the payload (i.e coded data)}&\text{[bytes]}\notag\\
%%G&\text{ is the generation size.}&\text{[-]}\notag\\
%%\tilde{q}&\text{ is the field data size (i.e 1 byte for field of size 256)}&\text{[bytes]}\notag
%%\end{align}

%%Rearranging \eqref{eq:packet_budget} for $P_{load}$ and inserting in inequality \eqref{eq:fit_video_gen} gives.

%%\begin{align}
%%GOP_{x}&\leq G_{max}\cdot P_{load}\\
%%GOP_{x}&\leq G\cdot (P_{total}-G\cdot \tilde{q}-O_{UDP})\\
%%GOP_{x}&\leq -\tilde{q}\cdot G^2+(P_{total}-O_{UDP})\cdot G\label{eq:2ndorderG}
%%\end{align}

%%In Figure \ref{fig:gensize_vs_gopsize} it is seen that the data contained in a generation is limited by the generation size itself and a function of the chosen galois field over which the coding is performed. This is because for increasing field size, larger coding vectors are needed. The applied principle in RLNC is to include the coding vector in each packet together with the coded packet\fxnote{Claim-back it up.}.

%%FIXME\fxnote{Conclusion from \eqref{eq:2ndorderG} should be stated, related to figure \ref{fig:gensize_vs_gopsize}}
%%FIXME\fxnote{Figure \ref{fig:gensize_vs_gopsize} out of place? Should it be shown when we discuss NC and then referred to instead..? EV}

%%\begin{figure}[h!]
%%\centering
%%\includegraphics[width=0.7\textwidth]{figs/gensize_vs_gopsize.eps}
%%\caption{The amount of source data contained within a generation of varying size for a fixed packet size.}
%%\label{fig:gensize_vs_gopsize}
%%\end{figure}


%\subsection{Summary}
%% Review important findings
%\fxnote{Comment on distributions found throughout video.tex}
%\fxnote{We should test a bit further the general conclusions made here... currently based on one!!!1!11 video.}

%\begin{enumerate}
%\item{The relative frequency of I-frames can be increased, without a significant increase in total filesize, to around a GOP of 20-40.}
%\end{enumerate}



%\clearpage

